Tomáš Pospíšek's Notizblock

Steuer-Software unter Ubuntu 12.04

TLDR:

$ unzip Linux_2011.zip 
$ chmod +x Setup.bin
$ ./Setup.bin LAX_VM /usr/bin/java
$ ./Steuern11 LAX_VM /usr/bin/java

Hab mir also die Steuer-Software für Schaffhausen runtergeladen:

$ wget http://www.sh.ch/fileadmin/Redaktoren/Download_Steuer-CD/Linux_2011.zip

$ unzip Linux_2011.zip 
Archive:  Linux_2011.zip
  inflating: Setup.bin

Setup.bin ist schon Mal nicht ausführbar.

$ ls -l Setup.bin 
-rw-rw-rw- 1 tpo tpo 78496982 Jul  9 17:54 Setup.bin

Na gut:

$ chmod +x Setup.bin
$ ./Setup.bin 
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
strings: '/lib/libc.so.6': No such file

Launching installer...

'SWING' UI not supported by VM.  Reverting to AWT.
Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:
java.lang.UnsatisfiedLinkError: /tmp/install.dir.8935/Linux/resource/jre/lib/i386/xawt/libmawt.so: libXext.so.6: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.load0(Unknown Source)
        at java.lang.System.load(Unknown Source)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at sun.security.action.LoadLibraryAction.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.awt.NativeLibLoader.loadLibraries(Unknown Source)
        at sun.awt.DebugHelper.<clinit>(Unknown Source)
        at java.awt.Component.<clinit>(Unknown Source)
        at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.h(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)
        at com.zerog.ia.installer.Main.main(DashoA8113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at com.zerog.lax.LAX.launch(DashoA8113)
        at com.zerog.lax.LAX.main(DashoA8113)
This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Der Installer räumt nicht nach sich auf, wenn man die Installation mehrere Male versucht, wird er einem das /tmp Verzeichnis vollmüllen:

$ du -sh /tmp/install.dir.8935
252M

Und, obwohl die Maschine hier 64bit ist:

$ uname -m
x86_64

... versucht der Installer eine 32bit Version zu installieren:

$ file /tmp/install.dir.8935/Linux/resource/jre/lib/i386/xawt/libmawt.so
/tmp/install.dir.8935/Linux/resource/jre/lib/i386/xawt/libmawt.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped

Nota bene, das Installationskript prüft sogar die Architektur:

$ grep "uname -m" Setup.bin 
                cpuName=`uname -m 2> /dev/null`
                cpuName=`uname -m 2> /dev/null`
        if [ `uname -m` != "ia64" ];

... ist dann offenbar trotzdem nicht im Stande die korrekte Java Version zu installieren.

Bemerkenswert ist auch, dass gemäss Debian x86_64 die am häufigsten eingesetzte CPU Architektur ist, und das dies hier ein stabiles "Long Time Support" Ubuntu 12.04 ist, und Ubuntu wohl das am häufigsten verwendete Linux ist. Ich weiss nicht auf welchen Linux Systemen Abraxas, die ein quasi Monopol auf Behörden Steuer-Software zu haben scheinen, getestet haben, mit meinem System kommt der Installer jedenfalls nicht zurecht.

Warum der Installer unbedingt ein ganzes JRE installieren versucht, wenn er dazu nicht fähig ist, und wo doch ein Java im trivialsmöglichen Pfad schon vorhanden wäre ist auch nicht wirklich klar:

$ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.4) (6b24-1.11.4-1ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
$ which java
/usr/bin/java

Eine Stunde herumpröbeln und im Code herumsuchen hat dann zu folgender Lösung geführt:

$ ./Setup.bin LAX_VM /usr/bin/java

Damit sagt man dem Installer, er solle das vorhandene JRE benutzen. Er ist aber leider nicht intelligent genug sich das zu merken. Beim Start der Steuer-Software muss man's wieder sagen:

$ ./Steuern11 LAX_VM /usr/bin/java

Man würde meinen, dass Abraxas:

$ grep abraxas *|wc -l
85

so gross sein würden und Errata sammeln bzw. ein Howto oder ein FAQ pflegen würden, aber dem scheint nicht so. Auch der Kanton kann da leider nicht weiterhelfen.

Es ist mir ein Rätsel, wie Softwarehersteller eine Umgebung, deren expliziter Anspruch ist portabel zu sein, derart vermorksen können.

Die Meldung der Steuer-Software nach dem Start grenzt diebezüglich an Sarkasmus:

Nun ja, wir sehen uns dann wohl nächstes Jahr wieder: 2006 Debian 2006 Ubuntu 2008 Ubuntu

Tomáš Pospíšek, 2012-09-26